\section{Previous work}

To our knowledge, no work on call-site optimization has been published
in the context of \commonlisp{}, though some practical work exists in
the form of code in certain implementations, as explained in
\refSec{sec-previous-ctors}.

The absence of published work is perhaps due to the many unique
features of \commonlisp{} functions, that make the task very
difficult, such as keyword arguments, generic functions with arbitrary
method combinations, etc.

\subsection{Inline caching}

One technique that is fairly common is \emph{inline caching},
pioneered by Smalltalk \cite{Deutsch:1984:ES}.  This technique is used
to avoid repeated method selection in a particular call site.  The key
observation is that, for a particular call site, often the same method
is concerned each time the call is made.  By caching the latest
method, keyed by the distinguished class argument, the system can
often avoid a costlier computation.

The purpose of inline caching being to reduce the cost of finding the
applicable effective method, it is not directly related to speeding up
function calls, but it has the effect of making calls to generic
functions faster.

\subsection{Ctors}
\label{sec-previous-ctors}

The CMUCL%
\footnote{https://cmucl.org}
implementation of the \commonlisp{} language uses a
technique that they call \emph{ctors} that can be used for call-site
optimization of certain functions.  This optimization was introduced
by Gerd Moellmann in 2002, and has since been included also in SBCL%
\footnote{http://www.sbcl.org/},
which is a derivative of CMUCL.  In particular, in CMUCL the technique
is used for the function \texttt{make-instance} which is often called
with a literal class name and literal keywords for the initialization
arguments.  When the name of the class to instantiate is a literal,
several steps in the object-initialization protocol can be simplified.

Most importantly, checking the validity of the initialization
arguments can be done once and for all, subject only to added or
removed methods on the functions \texttt{initialize-instance} and
\texttt{shared-initialize} and to updates to the class being
instantiated.

CMUCL accomplishes the optimization by replacing (using a compiler
macro) the original call to \texttt{make-instance} by a call to a
\emph{funcallable object} that is specific to the name of the class
and the literal keyword arguments given.  The \emph{funcallable
  instance function} of the funcallable object is updated as a result
of added or removed methods and modified classes as mentioned.
This technique can be used on other, similar functions.  For example,
\texttt{slot-value} is often called with a constant slot name, and
this fact has been explored by \sbcl{}.

Since the optimization is done as a manual source-code transformation,
it is applicable mainly to standard functions that can not change later
on.  The mechanism presented in this paper can be seen as an automatic
low-overhead version of ctors.

A similar mechanism (called ``constructor functions'') exists in
Allegro Common Lisp.  And the \clasp{} \commonlisp{} implementation%
\footnote{https://github.com/clasp-developers/clasp}
uses a similar mechanism for \texttt{make-instance},
\texttt{change-class}, and \texttt{reinitialize-instance}.

\subsection{Sealing}

Sealing is a mechanism that allows the programmer to freeze the
definitions of various program elements such as classes and generic
functions.  The work by Heisig \cite{Heisig:2020:ELS:Sealable} applies
to \commonlisp{} and can allow for certain call sites to be
optimized to different degrees, from bypassing generic dispatch to
fully inlining entire effective methods.

%%  LocalWords:  funcallable ctors Smalltalk SBCL CMUCL
